I've been promoted - my job title will now be 'Software Architect'. This seems to mean I'll be writing documents rather than code - any higher-level, and I'd need Mark Shuttleworth's spacesuit. Is this a good thing? Anyway, I celebrated by opening my last bottle of Debian wine. <spam>Unfortunately, I can't take up my new role until we have hired a replacement. UK-based developers who know Perl and ideally PostgreSQL might want to look at the job description, although I'd recommend sending your CV and covering letter to me directly. I don't get a referral bonus, it's just that I don't like what that agency does with your carefully-crafted application.</spam> I'd like to thank everyone who maintains LaTeX for their assistance in this matter. In other news, I'm studying a couple of Open University courses part-time - one on software development (i.e. UML), and one on interaction design. They're going well so far - I've had a couple of tutorials, and the first part of an assignment came back with good marks. I've been reading the Lean Software Development books by Mary and Tom Poppendieck. They seem to put Agile development into a 'respectable' historical context of similar improvements in manufacturing, which might be useful for persuading project managers.

A new release of Gnash, version 0.8.9, is due in the near future. Plenty of bugs have been fixed, but some users are still going to have problems playing YouTube videos. Here's a short explanation. At some point last year, YouTube started setting HTTP cookies in your web browser, to keep track of which of their video servers is nearest to your machine. This lets them provide a better experience for you (I guess). Here's a diagram of what goes on in your browser: As of Gnash 0.8.8, a workaround was added, calling an NPAPI function NPN_GetValueForURL to ask the web browser for the relevant cookies. New diagram: The downside is that this function was only added in NPAPI version 1.9. This means:

• Only the NPAPI plugin has this workaround, not any of the other gnash plugins (e.g. the native kparts one for Konqueror).
• While most browsers do implement NPAPI, not all of them have been updated to include this newer function yet. So the versions of Epiphany and Chromium shipped in Debian at the time of writing do not work with gnash/YouTube as far as I am aware (but Webkit has fixed this upstream).

What does Adobe's plugin do? I imagine it's something like the following: So, the good news is, this problem should almost certainly get fixed over the coming Debian release cycle, if only because all the browsers will get updated. In the meantime, disabling cookies (and removing stale ones from YouTube) is a workaround.

My employer moved offices to Park Gate about a year ago - there's a coffee/sandwich place just down the road, which I generally walk past to get my lunch. And it's got a sign outside: I can't believe I didn't notice that swirl sooner. It will join my picture of the FreeBSD naughty toys machine from DebConf7. In other news, Debian squeeze is being released as I write this. It's been a fun two years. :) Also currently happening is FOSDEM - this is the second year I've missed it, so I reckon I'll make an effort for next year. Instead, today I was at a choral workshop with the Soton Phil, which was really good fun - especially when we danced (yes) through the Osanna from Mozart's Mass in C Minor.

My paternal grandmother died a month ago today - I may have been quieter than usual since December. The most vivid memory I have of her is helping to collect runner beans from her garden - apparently this had been going on since the World War II "dig for victory" campaign. Her funeral was in Hastings on 10th January, and she was buried in Fairlight, in the Roman Catholic area of St. Andrew's - it was a very peaceful setting.

If anyone mentions Dropbox to me one more time, I will scream. I'm sure it's a wonderful solution, but I have deep misgivings about handing my data over to someone I don't trust. Besides, my synchronisation needs are not that complicated. Here are my high-level requirements:

1. Two way synchronisation between multiple clients and a central server.
2. Automatic syncs - no requirement for manual triggering.
3. Graceful handling of network outages, suspends, etc.
4. If using ssh, running from within my X session (so that it can access my ssh-agent)
5. Some assurance that my data will not be passed to other people (e.g. by running everything on servers I control, or encrypting all the data with keys only I hold)
6. Regular backups of the central data.

I've been playing about with several ideas - I know some people try to do this sort of thing with git, but I don't have a need for version control right at the moment, and merging conflicts could be far too complicated. I did hack together a script involving lsyncd and NetworkManager's dbus signals, but then realised that synchronising in the other direction would need something quite different, and it was getting a bit out of hand by that point. So my current favourite is actually GNOME's Conduit project. It ticks almost all of the boxes (apart from the backups, which should be simple to put together). There are some rough edges - the author has tried to delegate the minor detail that it's accessing an SFTP share entirely to GIO. But GVFS shares are not mounted automatically by Conduit - so I would have to browse to the remote folder in Nautilus before any synching would happen in each session. Bad. But looking at how Conduit is used, I don't agree with hiding the nature of the remote folder from the user. By all means use GIO to perform the mechanics of SSH and so on, but the user surely thinks of the remote server as something different to a local folder? So from a UI perspective, this should be made explicit. After all, the user has to deal with it at some level by switching to Nautilus to set up the connection. And since I cannot find an SFTP plugin for Conduit anywhere, this still leaves me in the unfortunate position of having to write code if I want a nice solution. Bah, humbug.

For those who are not aware, The Archers is a soap opera about rural life, broadcast on BBC Radio 4. Its website has recently been revamped. Unfortunately, I appear to be served the mobile version when I visit the front page (in all of Chromium, Iceweasel and Epiphany on Debian - admittedly not the most mainstream of browsers). BBC Mobile is doing some over-zealous useragent sniffing, it seems. Also amusing: there's a "Who's Who" database of Archers characters, and several of them share the birthday "1st Jan 1970". There was I thinking that Harry Mason and Fallon Rogers had a 15 year age gap... but no. This will be as a result of the underlying database storing values in Unix time, and having a default value of "0". An explanation of Unix time popped up in an episode of The Infinite Monkey Cage the other week, which was nice to hear.

Mwahahahaa, just a few moments ago, my local copy of gnash actually got past the RTMP handshake, and got a response from iPlayer. I need to be at work in around 8 hours, though, so no time to push this until tomorrow... and it needs some cleanup. Obviously, no audio has yet been played. Don't be silly.

Having studied librtmp over the weekend, it doesn't drop into gnash as neatly as I'd hoped. Gnash already has classes to implement NetConnection and NetStream, which it makes sense to use - but librtmp is designed to replace the need for such classes to exist. So it implements certain higher-level responses to various calls from the server, that are necessary when downloading a stream. Gnash probably needs to hook in instead, and let the flash application decide what to do in these cases. So more work required, and possibly changes to librtmp in future - but I've started fixing up Gnash's RTMP code instead, for now, and have sent a couple of initial patches to Savannah. I don't think YouTube exercises these code paths, so they're a little rusty - I hope to make more progress through the week.

Of course, now everyone wants to hate Flattr, and ban its buttons from Planet Debian. You can't coerce effectively over a network connection - unless you wave the DMUP at them. It's an interesting exercise to square this approach with the promise at the heart of free software - freedom. We let people sell our software for a profit; we're a billion-dollar industry now. (Red Hat alone is worth $1bn.) That's before we start counting the money made by the businesses whose servers rely on us. But a developer advertising for 25 per month in donations? They must be banned! We need those buttons - how else should I deduct reputation points from those who want us to pay a tithe to a third party? :)

So I studied the SWF 8 iPlayer a little - there are some simple rendering issues with Gnash that I'd like to come back to, but the biggest problem is obviously the media not playing. Looking at the network requests, wireshark says something about malformed packets - Gnash is getting as far as making RTMP requests, but the connection dies pretty quickly. My working theory is that there is a bug in the Gnash RTMP client code. This code was forked from rtmpdump, and has since been converted from C to C++, and a whole bunch of other stuff. It's quite possible that there is some change deep in the code which hasn't been copied back into Gnash - therefore, it makes sense to get Gnash building against librtmp properly, which is now a separate library. This, of course, means actually writing code. Eurgh. I try to avoid that when I can, but sometimes it is inevitable. :) When writing larger changes, I find it takes me longer to get acquainted with the existing code base - in this case, two code bases, since I have to understand librtmp at some level, as well. I'm not expecting to produce anything before the weekend, which is frustrating. It is also risky to write about stuff before you have completed it, because it can be a very public failure if you don't manage it!

There exist several different versions of BBC iPlayer. (Even if you don't care about the main iPlayer site, perhaps you might want to watch videos on BBC News one day, which uses the same code.) Here is some (reformatted) Javascript from the BBC's site:

a = glow.embed.Flash.version();
f = "";
f = a.major>=10 ? "10player.swf"
  : a.major<8   ? "7player.swf"
  : a.major==9 && (a.minor>0   a.release>=115) ? "9player.swf"
  : "player.swf";

It is clear that Flash 9.0.115 holds special significance; this was the version that introduced SWF Verification support. The 7player.swf file seems to have disappeared entirely - I get a "404 not found" error. That means there is still one version of the iPlayer which hopefully should not require implementing SWF Verification. Navigating around the site with Gnash declaring itself as version 8 (with a patch applied to fix Glow compatibility), only radio programmes attempt to play using this version, and even then not the live streams. (No, gnash still doesn't play anything, don't panic.) So it would seem to me that fixing Gnash's support for this SWF 8 iPlayer would be a good place to start.

So, with the GNASH_OPTIONS=writelauncher hint from last time, you have got a script which runs gnash. It is still running a remote SWF file, though - you want to modify that file to isolate a test case, and for that it will need to be on the local filesystem. First, look in the gnash-debug-1.sh script to find the URL for the SWF, and download it. It's the last option passed to gnash. In order to convince the file that it's still being served from the web server, you now need to swap the '-U' option in the gnash command line for a '-u'. This is enough for gnash 0.8.8 to play the file. Unfortunately, if you are running current git master, this does not work. You also need to feed the SWF from standard input to gnash - i.e. use '-' as the last option, and redirect the SWF file to the gnash command:

/path/to/gtk-gnash -u http://some/url [more options] '-' < downloaded.swf

If any of this is documented, I'm buggered if I can find it.

Gnash has moved from bzr to git, at least for the moment - Savannah's bzr setup is slow and unlikely to improve, so the choice is git or Launchpad, apparently. (Thinking selfishly, I'm a lot more familiar with git than with bzr, so I hope it stays this way.) My instructions from July have changed only slightly:

git clone git://git.sv.gnu.org/git/gnash
cd gnash
./autogen.sh
./configure --enable-renderer=agg \
            --enable-media=GST \
            --enable-gui=gtk \
            --with-plugins-install=system
make
sudo make install
sudo make install-plugins

Buried near the end of the bug reports wiki page is a useful tip for debugging - export GNASH_OPTIONS=writelauncher before starting the browser, and gnash will write out the instructions for starting a local copy. In practise, these instructions seem to appear as a file called /tmp/gnash-debug-1.sh, and that will reference a file matching /tmp/gnash-cookies.* - so don't bother trying to dig through the debug log. With this tip, it's possible to get the browser out of the loop, and focus on debugging gnash (which should be enough for most problems). At least, that's what I hope - I've spent the last hour or so just figuring this stuff out. Hmpf.

Dato pointed out on my post yesterday that I had omitted to link to the Ikea catalogue. And then it hit me - I am completely failing to monetize this blog! (Sadly, Ikea aren't in a position to give me any kickbacks right now.) Since my money would be spent on innovative Swedish design in any case, I present a new microdonations system: Flattr-pack. I'll add a "Flattr-pack this!" button to everything I write, and then you can send me furniture with one easy click. Unlike other systems, this has the advantage that no one will be taking a 10% cut of your donations. Awesome! Or maybe not. For those who don't know what I'm on about, Flattr is a website that lets you donate small amounts of money to other websites. It has been proposed to use this site to support free and open source software (FOSS). Now a quick modern anthropology lesson: in a 1998 essay titled "Homesteading the Noosphere", Eric Raymond conjectured that FOSS society is a gift economy; your reputation is proportional to how much you give away. At first sight, microdonations drop neatly into this system; after all, the users are giving money away, right? And yet somehow, I don't think those users are gaining much in terms of reputation. Not in the same way as if they reported bugs, say; joined a localization team; or even just turned up to conferences and volunteered to sit on the front desk. Both types of activity could be described as "donations" - but in one case, the donation benefits the whole community around the project, and in the other it goes to just a few top developers. It's a plain old exchange economy in disguise. I do hope that those users are not dissuaded from making the more generous donations just because it's more convenient to whip out a credit card. That would not be in their long-term interests, or those of the community as a whole. I fear this scheme could also incentivize some oddly inefficient behaviour; writing blog entries purely for their donation potential, say, or even content-free search-engine optimization posts. Speaking entirely personally, I do not plan to join in.

Today I bought two Ikea boxes. Possibly the best 8 I have ever spent - I still have a load of bits of paper to sort out, but now they're all hidden from sight in a sleek, black and chrome rivet-effect container. More than simply reclaiming my sofa from the piles of notes, they seem to point to a higher truth; they fit their purpose in a way that is hard to articulate, like some platonic Form. Taking complexity, and making it manageable; but more than that, elegant. At some point, I lost the ability to explain to my friends and family what it is I spend my spare time doing. I feel isolated; I cannot express what motivates me, or even what it is I do. In fact, sometimes I can't even describe it to myself. Perhaps I never could. I don't believe that you can buy happiness; but if I surround myself with metaphors, maybe I can buy clarity.

I've been ill this week. The only hacking I've been doing is of the cough variety. :) I think I'm recovering, though. This evening, I finally checked out LibreOffice, to get an idea what's going on - kicked off a build, joined the mailing lists. Some of the easy hacks look quite feasible, but there's always a bit of work to get started. The community looks very welcoming, though, so no problems there. The various Perl bits in the installer/build system seem an obvious place to get started. I've also got an eye on the mdbtools code - I theoretically maintain the Debian package, and have come close to forking it. But I aspire to be writing "real" patches, of course. I've been thinking about where I should put my development time over the next year or so, and LibreOffice is likely to be one of those places.

My humble RC bug squashing efforts for this week. I've saved them all up, because I don't want to spam Planet Debian too much... or alternatively, because I've been feeling ill Thursday/Friday and didn't do anything at all.

• #598619 in x11vnc NMU'd, after one false start, but at least I learnt something.
• #586849 and #586838 in mgltools- utpackages,geomutils confirmed fixed.
• Patch written for #592417 in mgltools-utpackages.
• Verified and NMU'd patch for #410130 in cryptonit.
• #590383 in rabbitmq-server confirmed fixed.
• Investigated why #589194 in openclipart hadn't been closed, although it was Anibal who eventually sponsored the patch.
• #599988 in lwjgl fixed and uploaded.
• Confirmed #599959 in sawfish closed from last week, after it got binNMUs.
• Patch finally written for #593856 in gnucash.

Note that quite a few of these were "cheating" by just closing bugs that someone else had written a patch/comment for, and the mgltools-* ones are in non-free software, so they won't have the same impact on the RC bug stats. Also, I've mentioned the gnucash and sawfish ones before, but they'll definitely be counted in the stats now..

I went shopping today, and inadvertently stole a very nice cardigan-like thing from a multinational clothing retailer. Enough anecdotes. Yesterday:

• NMU'd nut to fix bug #583371. I hear a co-maintainer is sought, so if you're into UPS devices...
• Downgraded bug #599909 in emacs23. Tempted to upgrade it again now it's reassigned to gtk-qt-engine, though.
• Asked for a binNMU to fix rep-gtk on kfreebsd-amd64.

Today:

• Filed a binNMU request for sawfish, which should eventually resolve bug #599959 on the back of the librep work I did earlier in the week.
• NMU'd python-sipe to fix bug #582998, where a non-DD had followed the NMU instructions rather literally; nice try. ;) If any non-DDs need a sponsor for RC bug fixes, do ask me by email.
• Downgraded bug #599463 in gstreamer0.10-alsa (formerly of mp3splt-gtk). It's now closed.
• Went ahead and NMU'd aptitude to fix bug #557580 and bug #594505. It'll be fine, honest; if you don't believe me, test the packages.

Looking at the weekly summary reports, we squashed a net total of 31 RC bugs last week. Of course, it's possible they'll get more difficult as we go along... but I'm hoping to see all the easy ones closed before the BSP two weeks from now.

Summary of yesterday:

• Investigated rep-gtk/librep-dev breakage, and NMUd librep. Got a libtool wishlist bug out of it as well.
• Cloned bug #584327 in python-rdflib to gcc-4.4 as a reminder to see if mips/mipsel is already fixed.
• Downgraded bug #580876 in ldc.
• Wrote a patch for gpib FTBFS, which occurs because of an interesting new cdbs/module-assistant problem.

I'm getting to the point where RC bugs actually keep me up at night. Very bad...

I took most of the weekend off, although took a look at an upgrade bug on e16. Turns out Tolimar's got it handled, right? :) Tonight I put together a tentative patch for bug #557580 on aptitude to make it respect configuration under /etc/apt/preferences.d/ - aptitude is written in C++, and I have had some recent exposure to that language at work. Unfortunately, it means aptitude takes most of an hour to build on my desktop. Since aptitude is an important package, I'm not yet entirely confident about my patch, and it's already half eleven, I think the NMU can wait a few evenings.